-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: debug log gRPC queries #19049
feat: debug log gRPC queries #19049
Conversation
* config option to log gRPC queries * clarify gRPC log comment * create var
WalkthroughThe recent updates introduce a new feature to the gRPC configuration, allowing the logging of gRPC queries. A constant for the default logging behavior and a new field have been added to the configuration struct, along with a corresponding parameter in the TOML configuration file. The gRPC server registration function has been modified to include this new logging option, which is now utilized during server initialization to enhance debugging capabilities. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
This comment has been minimized.
This comment has been minimized.
baseapp/grpcserver.go
Outdated
@@ -23,7 +24,7 @@ import ( | |||
func (app *BaseApp) GRPCQueryRouter() *GRPCQueryRouter { return app.grpcQueryRouter } | |||
|
|||
// RegisterGRPCServer registers gRPC services directly with the gRPC server. | |||
func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server) { | |||
func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server, logQueries bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an API breaking changelog?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added here e82a084
server/config/toml.go
Outdated
@@ -182,6 +182,11 @@ max-recv-msg-size = "{{ .GRPC.MaxRecvMsgSize }}" | |||
# The default value is math.MaxInt32. | |||
max-send-msg-size = "{{ .GRPC.MaxSendMsgSize }}" | |||
|
|||
# LogQueries if enabled will print an info log containing the query request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add the following here to keep confix up to date: https://github.com/cosmos/cosmos-sdk/blob/main/tools/confix/data/v0.51-app.toml ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't know this existed! Added here 8e56944
baseapp/grpcserver.go
Outdated
@@ -67,6 +68,10 @@ func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server) { | |||
app.logger.Error("failed to set gRPC header", "err", err) | |||
} | |||
|
|||
if logQueries { | |||
app.logger.Info("gRPC query received of type: " + fmt.Sprintf("%#v", req)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not put this as debug and use log filtering for the info you need? another config variable seems overkill here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thought here is, this will only be enabled in the event we are actively debugging something, and have an integrator to send me their info logs is much easier than asking to send massive debug logs and/or filter it themselves.
Happy to change it in this PR for the sdk, will probably keep as info for the fork for now though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is what filter logging was created for or one of the reasons. It would be much cleaner to ask an integrator to turn on debugging and paste "....." in the filter logs. This way they only get the logs you want. Currently this approach you will need to ask for a snapshot or they will need to search for the log along side all the other infos.
The filter would be to see blocks are being created and this debug log. So you as the debugger would make your life easier.
This is encroaching on devops territory which there are tools for, we dont want to make the sdk more complicated to run and debug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Np, will change sdk side
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry i meant no config changes, just a debug statement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a node under heavy load like ours (250 rps), this might make the debug logs impossible to grok. I know one can filter but it seems helpful for the logs to be somewhat manageable, and there are rare edge cases where this info is needed. I think a config makes the most sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this introduces two ways to do the same thing. feels like this will be confusing to users as if they try to filter for this log it wont show up since its blocked on another config value. We can add it but I feel its over kill for something already suported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can remove it, I just wanted to explain why I added it as a config in the first place. I am actually not familiar with the debug filtering at all so that's why this wasn't clear to me. Happy to remove it
baseapp/grpcserver.go
Outdated
@@ -23,7 +24,7 @@ import ( | |||
func (app *BaseApp) GRPCQueryRouter() *GRPCQueryRouter { return app.grpcQueryRouter } | |||
|
|||
// RegisterGRPCServer registers gRPC services directly with the gRPC server. | |||
func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server) { | |||
func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server, logQueries bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would instead directly supply grpcConfig
here instead. This future proofs us (even though Baseapp will be sunsetted soon) in case we need other fields or data when calling RegisterGRPCServer
.
@tac0turtle as per your request, I modified this PR to only be a debug log in place of a config option. CI seems to be failing due to rate limit. |
@@ -67,6 +68,8 @@ func (app *BaseApp) RegisterGRPCServer(server gogogrpc.Server) { | |||
app.logger.Error("failed to set gRPC header", "err", err) | |||
} | |||
|
|||
app.logger.Debug("gRPC query received of type: " + fmt.Sprintf("%#v", req)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the logger is passed directly from the app, maybe we should add a module key here:
Line 196 in 2cde8df
logger: logger, |
logger.With(log.ModuleKey, "baseapp")
). This will make the filtering easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the app.logger
should already have the module key set when it's set on BaseApp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@czarcas7ic could you update this real quick and we'll get it merged 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @alexanderbez, I think this is what you guys were asking for 1c00bb7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
simapp/app.go
Outdated
@@ -248,7 +248,7 @@ func NewSimApp( | |||
} | |||
baseAppOptions = append(baseAppOptions, voteExtOp, baseapp.SetOptimisticExecution()) | |||
|
|||
bApp := baseapp.NewBaseApp(appName, logger, db, txConfig.TxDecoder(), baseAppOptions...) | |||
bApp := baseapp.NewBaseApp(appName, logger.With(log.ModuleKey, "baseapp"), db, txConfig.TxDecoder(), baseAppOptions...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tip
Codebase Verification
The verification process has identified that the logger with the module key "baseapp" is used in simapp/app.go
and also in simapp/app_test.go
. However, the usage in app_test.go
uses a different key ("instance" instead of log.ModuleKey
). This indicates that the logger is not used consistently with the module key "baseapp" across the application.
Analysis chain
The NewSimApp
function has been modified to include a logger with a module key "baseapp". This change is consistent with the PR objectives and should enhance logging within the baseapp
instance. Ensure that the logger is correctly instantiated and that the module key "baseapp" is used consistently across the application.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that the logger with the module key "baseapp" is used consistently across the application.
ast-grep --lang go --pattern $'logger.With("ModuleKey", "baseapp")'
Length of output: 68
Script:
#!/bin/bash
# Search for any usage of logger.With with any string literal as the module key to check for "baseapp" usage.
ast-grep --lang go --pattern $'logger.With($_, "baseapp")'
Length of output: 332
runtime/builder.go
Outdated
@@ -29,7 +30,7 @@ func (a *AppBuilder) Build(db dbm.DB, traceStore io.Writer, baseAppOptions ...fu | |||
baseAppOptions = append(baseAppOptions, option) | |||
} | |||
|
|||
bApp := baseapp.NewBaseApp(a.app.config.AppName, a.app.logger, db, nil, baseAppOptions...) | |||
bApp := baseapp.NewBaseApp(a.app.config.AppName, a.app.logger.With(log.ModuleKey, "baseapp"), db, nil, baseAppOptions...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would do it automatically in NewBaseApp
itself
Description
Closes: #XXXX
There is currently an outstanding issue where some unknown gRPC query is causing cache to be polluted, causing gas_used on the node in which this query is called to differ from what is expected and cause a last results hash error. Figuring out what this query is has been very difficult.
This PR introduces a debug log for each gRPC call for easier future debugging.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
in the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...